thanks @michaeljfazio , this is thinking outside the box for sure ! :)

But while, it may fix the immediate problem by effectively literally throwing more cpus at it, but it's just a temporary fix and not one that address the algorithmic issue.

seems to me we should looks at:
https://github.com/primetype/poldercast/blob/master/src/poldercast/vicinity.rs#L27-L32
and
https://github.com/primetype/poldercast/blob/master/src/poldercast/vicinity.rs#L48-L53

which both transform an already ordered BTreeSet into a Vec which is then sorted with another comparison and when this is all sorted then only the beginning max items are looked at.

@vincenthz is right here.

The available are in a BTreeSet for it makes it easier for the ring module, however it is not efficient at all for the case of the vicinity.

Here we need to search for something more in depth. Maybe have the vicinity module keep an indexing of the available nodes to allow a fast selection of the closest nodes by topic.

Agree with everything in this thread. Initially wanted to move to an insert sort data structure for vicinity nodes but that looked like it would be too much of a departure from how layers are currently populated. This was a low effort low risk attempt at an interim performance gain for sure 👍